home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / rfc / rfc687 < prev    next >
Encoding:
Text File  |  1991-04-20  |  5.9 KB  |  171 lines
  1. Network Working Group                              David C. Walden (WALDEN@BBN)
  2. Request for Comments: 687                                              Jun 1975
  3. NIC #32654
  4.  
  5.  
  6.           IMP/Host and Host/IMP Protocol Change
  7.  
  8. This note sketches the design of an expansion to the
  9. IMP/host and host/IMP protocol which will include among other
  10. things the possibility of addressing hosts on more than 63 IMPs.
  11. Our intention in this expansion is to correct certain existing
  12. limits without fundamental changes in the philosophy of the
  13. IMP/host protocol; i.e., while many issues which would represent
  14. fundamental changes to the IMP/host protocol are presently under
  15. discussion in the world-wide packet-switching com unity, we are
  16. not able to undertake massive fundamental changes on a time scale
  17. compatible with the short term needs for network improvement
  18. (e.g., already there are almost 60 IMPs).
  19.  
  20. The following paragraphs cover each of the major
  21. characteristics of the expanded protocol. A knowledge of Section
  22. 3 of BBN Report 1822 is assumed. As is discussed below, the
  23. expanded protocol is backwards compatible.
  24.  
  25. 1. Expanded Leader Size. The leader will be expanded from two
  26. to five 16-bit words. This will provide space for necessary
  27. field expansions and additions.
  28.  
  29. 2. Expanded Address Field. The address field will be expanded
  30. to 24 bits, 16 bits of IMP address and 8 bits of host address.
  31. This expansion is more than adequate for any foreseeable ARPA
  32. Network growth.
  33.  
  34. 3. New Message Length Field. A new field will be added which
  35. will allow the source host to optionally specify the message
  36. length (in bits) to the IMP subnetwork. The IMP subnetwork may
  37. be able to use this information (when available) to better
  38. utilize network buffer storage. The destination host may also be
  39. able to use this information to better utilize its buffer
  40. storage. This field will be 13 bits wide.
  41.  
  42. 4. Expanded Handling Type Field. The handling type field which
  43. now is used to distinguish between priority and non-priority
  44. message streams, etc., will be expanded to eight bits. This
  45. expanded field will provide for the possibility of a number of
  46. parallel message streams having different handling
  47. characteristics between pairs of hosts; e.g., priority,
  48. non-priority, varying numbers of packets per message (see below),
  49. unordered messages (i.e., the present type-3 messages), a message
  50. stream requiring guaranteed capacity, etc. Note that only some
  51. of these facilities will be available in the near term.
  52.  
  53. 5. Source Host Control of Packets per Message. The possibility
  54. will exist for the source host to specify a message stream which
  55.  
  56.                                 -1-
  57.  
  58.  
  59. will use a given number of packets per multi-packet message (e.g,
  60. two packets per message or five packets per message). Since the
  61. IMP network will not have to use eight packet-buffers for
  62. reassembly purposes, as at present, this may result in better
  63. services for such messages. This will help users who need both
  64. low delay and high throughput.
  65.  
  66. 6.    Unordered (type-3) Message Change. Unordered messages will
  67. be indicated by a handling type rather than by a message type as
  68. at present. This is compatible with the need to check the host
  69. access control capabilities of all messages. This will provide a
  70. slight backward incompatibility for the three or so hosts which
  71. presently use type-3 messages in their research.
  72.  
  73. 7.    Change in Format of Fake Host Addresses. The For/From IMP
  74. bit will be eliminated. The fake host addresses will be the four
  75. highest host numbers (e.g., IMP Teletype will be host 252).
  76.  
  77. 8.    Addition of a Parameter to the IMP to Host NOP. The IMP to
  78. host NOP will have added to it a parameter specifying the address
  79. (IMP and host number) of the host.
  80.  
  81. 9.    Backward Compatibility. The old and new formats will be
  82. supported in parallel in the IMPs for the foreseeable future to
  83. allow gradual phaseover of host software. A host will be able to
  84. specify to its IMP whether the old or new formats are to be used;
  85. thus, it will be possible for the host to specify switching back
  86. and forth between the two modes for debugging purposes. The
  87. specification of the mode to be used will be possible via a
  88. proper choice of format in the host to IMP NOP message; the IMP
  89. will use the mode of the host to IMP NOP message the IMP has
  90. received. Further, a host may select to use either the old or
  91. new format without needing to know more about the other format
  92. messages than to discard them should they arrive. The IMP will
  93. initialize by sending several NOP messages of each type to give
  94. the hosts its choice. Although a host not implementing the new
  95. format will not be able to address hosts on IMPs with IMP-number
  96. greater than 63, the IMPs will wherever possible do the
  97. conversion necessary to permit hosts using the old format to
  98. com unicate with hosts using the new format and the reverse.
  99. Finally, it will be possible to convert the leader format from
  100. old to new or the reverse without knowledge of the message type.
  101.  
  102. 11.    Non-blocking Host Interface. A mechanism will be provided
  103. which allows the IMP to refuse a message from a host without
  104. blocking the host interface. This mechanism will permit the IMP
  105. to gather the necessary resources to send the refused message and
  106. then ask the host to resend the message. Finally, the host will
  107. be permitted to ask to be able to send a message and be notified
  108. when it is possible without requiring the message to actually be
  109. sent and refused.
  110.  
  111. 12.   Maximum Message Length. The maximum number of bits of data
  112. in a message may be reduced by a few bits.
  113.  
  114.                                 -2-
  115.  
  116.  
  117.      We are presently working out the details of an
  118. implementation plan for making the above changes to the IMP
  119. software. We will distribute an implementation schedule and
  120. other necessary information (e.g., format details) in plenty of
  121. time for hosts desiring to use the new protocol as soon as it is
  122. available to implement in time.
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.                                   -3-
  171.